Many modern applications are browser-based so as to render these applications portable, and to provide the advantage of zero-install requirements on a computer system. For various security reasons, current browsers (e.g., the Internet Explorer (IE) browser developed by Microsoft Corporation of Redmond, Wash. State, and the Mozilla browser developed by the Mozilla Organization) implement policies, typically known as the “Same Origin Policy”, that prevent one application being supported within a browser instance and coming from a particular domain (e.g., www.domainA.com), from communicating with another application supported in a further browser instance and coming from a different domain (e.g., www.domainX.com), even though both browser instances are executing on the same computer system.
FIG. 1 is a block diagram illustrating a client machine 10 that hosts a browser application, for which three browser instances 12,14 and 16 have been opened. Each of the browser instances 12,14 and 16 may be viewed as providing a “thin client” for the relevant browser-based application. Specifically, browser instance 12 is shown to support an application A client, browser instance 14 is shown to support an application B client, and browser instance 16 is shown to support an application X client. Turning to the server side, a first domain 18 (e.g., domainA, identified by the domain name “www.domainA.com”) is shown to include respective application servers 20 and 22 for each of the browser-based applications A and B. Browser instance 12 communicates with the application server 20 via a network 23 (e.g., the Internet), and the browser instance 14 communicates with the application server 22, again via the network 23.
As each of the browser instances 12 and 14 supports an application client for a browser-based application at a common domain (e.g., domainA), communications between the browser-based applications A and B is permitted, in terms of the “Same Origin Policy”, on the client machine 10, and specifically between the browser instances 12 and 14. These communications are indicated by the line 24.
However, turning to the browser-based application X, which is supported by the browser instance 16 and application server 28, and hosted on the domain 26 (i.e., the domainX identified by www.domainX.com), communications between the browser instance 16 and the other browser instances 12 and 14 is prohibited in terms of the “Same Origin Policy” as a result of the browser-based application X being supported on a different domain from the domain on which the browser-based applications A and B are supported.
To enable communications between browser-based applications that are hosted on different domains (e.g., domains 18 and 26), one option is to modify the applications so that communications occur between servers supporting the relevant applications, as indicated for example by the arrow 30. However, such modifications to the browser-based applications may be problematic for a number of reasons, not least of which is that access is required to both of these applications. Another manner in which communication between browser-based applications hosted on different domains may be facilitated is for a browser instance (e.g., browser instance 14) associated with a particular domain (e.g., domain 18) to issue a page request to an application server (e.g., application server 28) on a different domain (e.g., domain 26). However, this method is disadvantageous in that it involves a server round trip for a page to eventually load within the browser instance 16, this round trip potentially being expensive in real time scenarios. The arrows 32 in FIG. 1 indicate this communication path.
FIG. 2 is an interaction flow chart illustrating the communication of message content from an application, associated with the domain 18 (i.e., domainA) to an application associated with the domain 26 (i.e., domainX). As illustrated in FIG. 2, following identification of message content at block 34, the application client 12 at block 36 communicates the identified message content to the application server 28, the application server 28 being associated with a different domain from the domain with which the client application 12 is associated. At block 38, the application server 28 receives the message content, and possibly performs a function utilizing this message content. At block 40, the application server 28 then communicates a result of the function to the application client 16, which is again associated with the same domain as the application server 28 (i.e., domainX). At block 42, the application client 16 may display the result of the function, for example as a web page. It will be appreciated that the methodology discussed with reference to FIG. 2 involves the “round trip” to the server, which presents the disadvantages discussed above.